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Subject: A Proposal for Processes to be Used in the Supervisor 


Summary 


This memo ‘proposes that a facillty to provide special 
processes for use within the hardcore supervisor be made part of 
the standard Multics system. 


The Introduction shows why ae special class of processes 
should be avallable to the supervisor, and how these. processes 
must differ from the standard processes. The next section 
describes the actual implementation at a moderate level of 
detail. The last section presents a scheme for using such a 
process for the TTY [Interrupt handler. 


A glossary of jargon terms its provided, as Appendix V. 


This facility has) been Implemented and tested in an 
experimental verston of the Multics system. Work is underway by 
several people to make use of these processes to simplify certain 
areas of the hardcore supervisor. 


Multics currently makes no use whatever of multiprogramming 
within the supervisor. This results fn highly convoluted coding 
In many parts of the system where a module running fn any one 
process tries to multiplex itself so part of its algorithm seems 
to be executed asynchronously. For example, the TTY Device 
Control Module (DCM) simulates a process for each terminal, with 
its own scheduler and undocumented synchronization facility. In 
many other cases, something fs done In-line that doesn't really 
need to be done synchronously. For example, in the page fault 
path the faulting process currently checks the paging device to 
see If it is getting too full, and if so moves some pages. to 
disk. This causes an unnecessary delay for the faulting process, 
and requires the page-moving algorithm to execute In a severely 
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liaaited environment (fault-side, interrupts masked, can't wait 
for 1/0 or _ tlocks). For another example, some 1[/0 interrupt 
handlers currently execute long programs (taking up to two CPU 
seconds) in the same severely limited environment, requiring 
complicated (undocumented) conventions for co-operation with the 
processes that requested the 1/0. 


One can view the page-moving program or interrupt handler as 
a special kind of process that has absolute priority (it always 
runs to completion) but must run in a limited environment. By 
locks or by masking, the programs ensure a single sequential flow 
of control, as by: | 


check_paging._device: procedure (); 
set local lock; 
if should_run then run; 
unlock local lock; 
return; 
end; 


A program like this can be made into a real process. The 
preceding fragment might become: 


paging_device_process: procedure (); 
while true do; 
wait for wakeup; 
if should_run then run; 


end; 


and a call to check _paging_device would become acall to send a 
wakeup. 


In summary, there are three reasons why a program may need 
one or more dedicated processes: first, the algorithm may require 
a process per device, as In the TTY DCM; second, {it may he 
inconvenient to perform some complex oneration in the limited 
environment in which one happens to discover that it needs to he 
done; and third, [ft may be inefficient to perforn the operation 
in the critical path In which one happens to discover that it 
needs to be done. The iast point is meant to inctude the case of 
a program that requires more CPU time than one process can get, 
in order to scale up its performance in a very large system. 


These problems are shared by programs in all rings, both 
user programs and system programs; however, | shall attempt a 
solution only for the hardcore supervisor (ring zero). Let us 
assume that processes are readily available fn ring zero for any 
purpose, and examine some likely applications to get a feel for 
the properties such processes must have. This cholce of examples 
does affect the resulting design. 


The handler for any external Interrupt could run fina 
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process of its own, and the fnterrupt would merely cause a 
wakeup. Where interrupts are multiplexed (as by the 10M) each 
channel's handler could have a process. Such a process would he 
started when the 1/0 device (or whatever) was attached, and would 
destroy itself when the device was detached. its program shouid 
be specified when it is created; if the program is shared (e.g. 
printer driver shared by all printer processes) then an argument 
to the program should specify which device to run. This leads to 
the primitive 


FORK (erocedure: argument) 

which creates a new process that starts with the call 
procedure (argument) 

and the primitive 
DESTROY_ME () 


which stops and obliterates the process which calls it. Clearly 

the handler needs to block while awaiting the next interrupt, so 

a full set of IPC primitives should be available to it. The 

program should be allowed to use the virtual memory (take page 

faults) so it can run fn amore normal environment, and avoid the 

expense of wired code and data. The scheduler should provide = as 
fast response as. the 1/0 device may require. | 


Another application Is in resource managers to remove pages 
from core or from the paging device, to remove segments fron the 
AST, to remove processes from the eligible list or from the APT, 


etc. Such processes must be created very early in 
initialization, when the function they help implement is not yet 
usable by FORK. Thus page faults are not allowed in creating, 


scheduling, or running a page control process. 


These examples show processes that still run in a somewhat 
limited environment: they must not use the facility that they are 
implementing, and must be trusted by the supervisor because’ they 
must execute entirely in ring zero. Finally, using processes in 
any application has to be competitive in "cost" so that no 
programmer has to choose between readability and efficiency. 


An ordinary process of the sort currently created for each 
user could meet most of these requirements, with sultable changes 
to keep it in ring zero. However, it is cumbersome, and_ has 
features which cannot even be initiallzed by the creating process 
until system Initialization is nearly complete -- for example, it 
has a per-process directory (PDIR) which clearly cannot be 
created until page control, segment control, and the file system 
are all in operation. A simpler type of process must be 
introduced for use Inside the supervisor. Let us dub the new 
type He-process and the old (ordinary) type M-process, for this 


discusston. As a design goal, | choose to make the H-process as 
simple as is consistent with providing a normal program-execution 
environment. This should also minimize the "cost" of the 
H-process. The approach taken is to strip away all costly 
features that don't seem to be needed by aii processes. By and 
large, the H-process could regain a feature by explicitly 
initializing it. 


First, an H-process can run only in ring zero; thus we can 
eliminate the stack array used by the ring-crossing hardware. 
The programs it can run are totally pre-linked; the linker is 
unused and may be disabled. The address space could only he 
extended for data segments and only by explicit calls. Here its a 
very definite design choice: | choose to disallow this extension 
of the address space, in consequence of which I discard the KST. 
This means that the process can never take a segment fault: ft 
can't use the file system; [!t can address non-hardcore segments 
only through explicit calls on segment control. Now the PDIR 
can't be touched, so discard it; fit normally contains a segment 
called PIT by which the system passes initial arguments to a 
M-process -=- discard this too, using a few words in the PDS. for 
the (greatly reduced) initial conditions. At this point, only 
two per-process segments are left, PDS and DSEG, without which 
the H-process could not run at all. We have reduced the cost of 
the H-process to four pages + two ASTE's; Appendix I! describes a 
way to reduce the cost to one page + one ASTE. 


Notice that | have removed features by removing data bases. 
The features that are left, such as inter-process 
synchronization, paged memory, etc. seem to have very little 
incremental (per-process) cost, perhaps because their data bases 
and code are global. 


\n H-process can take page faults, service interrupts, and 


compete with M-processes in the scheduler's queues. The 
restrictions on it are less severe than those on fault-side or 
interrupt side programs which ft might replace. It can totally 


avoid taking page faults (e.g. for a page control process) by 
executing only in wired-down code, and can therefore be used as 
deep in hardcore as required. However, it Is poorly suited to 
the outer layers of the supervisor since it can't readily use the 
file system, and therefore can't interface to user processes. 
M-processes should be made available for outer-level applications 
in the supervisor (including ring one), and for user 
applications, but that is outside the scope of this project. 


Details of fo) ed _j n I 


Multiprogramming is provided by pxss, using te_data as the 


principal data base, It must be turned on by execttion of 
tc_init before it will function normaiiy; however, pxssswait and 
related entries are simulated during inittaltzatton by looping tn 
wired_fim. tc_init is currently invoked very late in 
initialization, so that page control (as a test case) cannot use 
multiprogramming. 1! propose to call tc_init early in Collection 
One, before page control is initialfzed. In this environment, 


all segments are unpaged and in core. This state is called the 
high-water mark because the core requirement is at its maximum. 


tc_init contains two steps: first, initialize all the 
threaded lists and other data [in tc_data; second, create the 
initializer process and all idle processes. The first step does 
not involve any references to data or procedures not present in 
Collection One, and therefore causes no problems. The second 
step starts any extra CPU's, and creates a PRDS for each such 
CPU, as well as a PDS and DSEG for each idle process. Let us 
assume that the extra CPU's are not started until late in 
initialization (to avoid two-cpu bugs); the remaining problem is 
the creation of two new segments for the single idle process. 
Any additional processes which may be created (e.g. for page 
control) will also require two new segments. The tnitializer 
process gets to keep the ortginal PDS and DSEG. 


Other conditions to be met in order for pxss_ to perform 
properly: those faults and ftnterrupts used by pxss must be set 
up; aonumber of routines and data segments must be moved into 
Collection One; FORK and DESTROY_ME subroutines must be provided. 
However, the only problems worth further discussion arise from 
the requirement for a segment-creating primitive available to 
process creation, which must be able to work even before paging 
is available. 


Segments (for PDS or DSEG) could be created unpaged 
initially, like segments read in during Collection One; however, 
update_sst_pll, which makes segments paged later on, would have 
difficulty finding the new segments. Any time after init_sst is 
run (which its very early) a paged segment can be created, taking 
a free ASTE and free page frames from appropriate lists. 
Existing page control entries could be used to create and wire 


pages; this approach was taken in the first experiments. 
However, these entries (e.g. wire_wait) ought not to be invoked 
when page control is not yet initialized -- if, for example, no 


free page existed, they might reference the FSDCT before it is 
addressable. 


A new subroutine, GETSEG, will be written, to be used during 


both initfalization and normal operation. lt will get an 
unthreaded ASTE and Cif during initialization) will assign page 
frames, ft will not wire the pages; that remains the caller's 


responsibility. 


It is essential that there he sufficient core left when 
Multics is at the high-water mark for several tasks to be 
created. This requirement is about four pages per task. The 
high-water mark fs already very close to the 128K minimum size of 
Multics main memory, but testing can proceed using a 256K systen. 
Appendix | describes one way to reduce the high-water mark, by 
removing segments from Collection One. 


Of course, wiring down more pages of core will of necessity 
degrade system performance. Most PDS's and ODSEG's can be 
unloaded by traffic_control, but at least some hardcore tasks 
won't allow that. It is useful to reduce the memory requirements 
of H-processes to reduce the impact on system performance and on 
the high-water mark; Appendix It describes a scheme for 
shrinking the per-process segments. Each H-process aiso costs 
two small ASTE's for its private segments, and one APTE, 
amounting to 64 words of core. Since the AST and APT can readily 
be made larger, this cost is important only for applications 
requiring hundreds of H-processes. 


Sone fncrease in overhead of traffic control -should be 
expected, due to more frequent interactions by H-processes. This 
loss of throughput can be countered by a better implementation of 
the process-switcher. The only other performance degradation to 
be expected is an increase in response time when’ Interrupte-side 
programs are moved into supervisor tasks, and this would probably 
not affect system throughput. On the other hand, system 
throughput may be [improved by moving certain housekeeping 
functions out of critical paths and by making use of multiple 
CPU's in bottleneck areas. 


An H-process may demand very fast response, which should be 
controlled by aepriortty attribute used by pxss. Such an 
improvement is not part of this proposal, since acceptabie 
performance can be achieved by ustng a different WAIT entry that 
guarantees fast response, Nevertheless, it has to be done 
sometime. Some scheduling requirements may not be adequately 
expressable by static priorities. This fs an example of a 
limitation in pxss that may prevent optimum performance; such 
probleinms become more complex as more processes co-operate on 
particular computations, . 


Moving TTY DIM interrupt side processing into an H-process 


Currently the Datanet-355 front-end processor returns status 
events by sending Multics a particular interrupt. The handler 
for this interrupt, dn355$tnterrunt, examines a mailbox at 
location 1400 to find the status word, performing an involved 
inter-computer ritual. For each status word ft calls ttv_inter. 
Every three seconds pxss calls ttv_interSnoll, in case there 
aren't enough Interrupts to drive the program. There is an 
interlock between tty_inter and tty_Itnter$poll so both are not 
active at once. 


It is. possible to restructure this as follows: The handler 
for the 355 interrupt, tty_wiredtinterrupt, merely sends a 
wakeup. A dedicated H-process, executing dn355%ttv_process, 
receives the wakeup, then performs the inter-computer ritual and 
calls tty_inter as required. Every three seconds opxss-_ calls 
tty_wired$poll, which sends the same wakeup and sets a flag. If 
dn355Stty_process finds the flag set, it calls tty_interspoll. 
dn355Stty_process goes blocked when it runs out of work to do. 


This scheme permits dn355, tty_inter, their uttlity modules, 
and two data bases to be unwired, releasing about ten pares of 
core. No further change ts required except to fix ae locking 
strategy that only works when interrupts and page faults are not 
allowed. All other interrupt handlers get better response since 
they no longer have to wait while tty_inter runs. (ttv_inter 
takes up to two seconds; to make matters worse, the 355 is 
assigned the highest prfority interrupt cell.) 


On the other hand, each 355 interrupt might pare itn all ten 
of the pages we just unwired, plus two pages of stack. The extra 
core is really available only when 355 traffic is light. 
Furthermore, the TTY DIM will respond more slowly to interrupts, 
since the scheduler imposes a considerable delay. This is a 
serious problem since the TTY DIM fs ontimtzed for 195%-tyne 
terminals that require program intervention to go from writing to 
reading; the program ignores characters tvned jin before it 
changes its [Internal state from writing to reading even if no 
external action was required. The user with a non-locking 
keyboard may begin typing before the TTY DIM begins listening, 
even in the current system. 


This problem can be solved without delving into the 355 
code: the write DCW list created by tty_inter could chain into 
the read DCW list instead of terminating. This would result in a 
noticeable improvement even over the current system and make TTY 
process response relatively unimportant. 


The restructuring (but not the DC!! list chaining) has been 
done and tested in an experimental system, using the improved 
WAIT' (see Appendix It). Response time was found to average 
.2%.2 seconds worse than that of the standard system. The 


experiment should be performed again to refine this measurement. 


goals to continue’ using this fixed data layout for the PDS and 


PROCESS-INFO, but it may later prove too inflexible. An 
H-process should be able to grow by adding to itself some of the 
features normally associated only with an M-process. In order to 


avoid reserving large blocks of data in all processes' stacks for 
features that only some use, we could reserve a relatively small 
block of pointers, accessed by name, that would point to the data 
items allocated in whatever segment is most appropriate. The 
Network software already uses such a scheme -- its only cell in 
the PDS contains an index into a system-wide table. 


The DSEG is currently a paged segment of which only about 
256 words are used for hardcore segments. Clearly it can he made 
an unpaged segment {ff core control Is made able to handle such; 
alternatively, page size could be reduced to 256. But closer 
examination of the DSEG suggests an even more fascinating 
solution: the only SDW's for which our hardcore DSEG differs 
from the template are those for the PDS, PRDS, the DSEG itself, 
and several abs-segs. This suggests that we can save core (at 
the expense of simplicity) by fabricating the NSEG whenever the 
process fs to be run. The SDW for the PDS can be saved in the 
APTE; the PRDS SDW is already being patched every time an LDBR is 
done; the DSEG SDW would not be changed since [ft would always 
point to the scratch DSEG ft lies ins and the abs-seg SDW's can 
be saved [n the PDS. This can be thought of as sharing the 
current ftdle process DSEG with other H-processes. 


Combining these tricks can reduce the per-process memory 
requirements by almost 75% for the hardcore-only tasks. 


Both of these changes have been made and tested in an 
experimental system. 


Appendix II . 
Miscellaneous changes required hy this system 


A. Descriptor segment creation. 


A DSEG is normally created by plm$hc, which in the current 
system copies the hardcore-segment-number portion of whatever 
DSEG it is running with. (template_dsez is still heing 
initialftzed but is never’ used.) pim has to he moved. into 
Collection One, modified to run before paging is avatlable, and 
modified to use the SLT to determine which SDW's to copy. 


If plm$he is invoked early in Collection One, it produces a 
DSEG with the segments unpaged. A routine, set_sdw_in_all_dsegs, 
has to be provided, to be called by update_sst_pil whenever it 
changes an SDW In the initia’*izer's DSEG with the intention that 
it affect all address spaces. segment_loader, ftnitialize_dims, 
and delete_segs can use set_sdw_in_all_dsegs too. 


One field in a DBR value contains a segment number for. an 
array of stack segments, for use in automatic ring crossings. 
Fortunately an H-process doesn't need this field. tts value is 
not determined until all segments are loaded, at which time 
init_sys_var fills it in for the initializer; init_sys_var has to 
be changed to set it in the APTE and fn the register, 


These chanzes have been made and tested, 


B. PNS creation. 


build _template_pds copies a stack header and a stack frame 
into template_pds; in so doing it messes up the tnitializer's 
stack. This module ts eliminated, since the header can be merged 
with the template by those programs that create new PNS's, 
bulld_template_pds very cutely inittalizes the stack such that a 
"return" will transfer control to init_proc, the normal M-process 
starting point. However, pxss has to observe that it is running 
a process for the first time in order to do the proper rettirn. 
The requirement that an H-process start in an arbitrary procedure 
forces a change: pxss executes "call stack_OSfirst_proc 
(stack_OSfirst_arg)" in the special case instead of "return". It 
turns out that init_processor recefves control in this way when 
it starts the bootload CPU, since to pxss the Inittalizer process 
looks like it has never run before. | 


bootstrap2 can't initialize the pointer to signal_ in. the 
stack header Calthough the comment says it does) so 
initialize_faults$fault_init_two does {It later. By moving 


Signal. into Collection One, this can be cleaned up. 


These changes have been made and tested. 
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C. Control flags. 


Assorted flags have to be added to the APTE: 
ehardcore_process, .use_hardcore_dsesz, and .always_loaded. if 
-use_hardcore_dseg then the .dbr ceil is really an SDW for the 
PDS. Other flags have to be added to wired_hardcore_data: 
$page_fault_works, S$segment_fault_works, and $init_segs_gone. 


D. Certain deficiencies in the scheduler. 


One little known property of the current scheduler is that a 
process cannot lose its absolute priority (eligibility) unless it 
either takes a timer-runout/pre-empt [nterrupt while running in 
an outer ring or explicitly calls BLOCK. Since part of BLOCK is 
outside of ring zero and therefore not available to an H-process, 
and since fnterrupts are masked while running in ring zero, an 
H-process wlll keep its eligibility even if it uses WAIT, the 
normal ring-zero synchronization method, and will attain the 
highest possible priority. (CIif any process loops in ring zero, 
it will tie up the CPU forever.) 


Allowing loss of eligibility by pre-emption in ring zero has 
other implications, requiring that eligibility be given up by 
WAIT because of assumptions embedded [In all. hardcore’ locking 
strategies, etc. | performed some experiments in this direction, 
concluding that even if $f could find all the ramifications of 
such a change, including re-tuning the system, the change would 
have to be made and defended separately. This area remains open 
to anyone wth a particular Interest in performance effects. 


For the H-process running the TTY DCM, WAIT was an 
unsatisfactory synchronization primitive, as it left the process 
loaded and eligible indefinitely. 1 could have introduced a 
slightly different version, WAIT_and_do_what_!_want, but itnstead 
t adapted a different fundamental mechanism originated by David 
Reed, that has been advocated as ae primitive capable of 


implementing both WAIT and BLOCK. Reed will soon publish an RFC 
describing his model, To) | shall merely describe the 


implementation. 


A shared memory cell is used to pass the Information as_ to 
whether or not an event has occurred. This cell is provided by 
the caller of WAIT’ or NOTIFY', which fs not inconvenient when a 
shared data base exists anyway, and which avoids the allocation 
probtems of WAIT and BLOCK. The cell changes to a new state (in 
fact it ts incremented) every time the event occurs (every time 
NOTIFY' is called). WAIT' is given both the cell and the state 
it had when the caller first decided to wait; ft returns whenever 
the cell contains some newer state. A list of processes waiting 
in this way ts needed, so NOTIFY' can awaken’ them. In my 
implementation, the cell must be wired (since it is examined 
under the APT lock) and at the same address in every orocess 
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using it (since the address is used as a readilv-available tnique 
identifer). 


NOTIFY' always awards high priority to an awakened process 
to Improve response to Interactions, Stnce the averasce delay for 
the process to becone eligible in the normal way is three seconds 
Cunless system load ts very light), | had to make NOTIFY' award 
eligibility as well. The process will run as soon as the 
lowest-priority running process leaves ring zero. and sets 
pre-empted. 


For best response, the pre-emnt should be allowed even in 
ring zero. Most of the problems with pre-emption in ring zero 
can be avoided if the pre-empt doesn't take away eligibilitv, but 
merely causes the highest-priority process to regain the CPl!!, 
This scheme should be tried as it should make TTY process 
response adequate for emulat’on of interrupt-side behavior. 


The response time should be determined by a priority 
parameter associated with the process rather than by which ‘AIT 
the process calls. Future applications of H-processes will make 
such a feature in pxss more desirable, 


The WAIT' primitives have been tested in an exnerimental 
system. 


Appendix IV 
Calling sequences of new routines 


A. FORK 
Usage: 


declare create_supervisor_task entry (char (*), entrv (pointer), 
: nointer, bit (36), bit (38)); 
call create_supervisor_task (sroup_id, F, arg_nointer, 
return_proc_id, return_code); 


1) group_id | is process group name of new process. 
(1 nput) 
2) F | is starting Procedure of new process. 
(input) 
3) arg pointer Is passed to F in the new orocess. Clnoit) 
4h) return_proc_id identifies the new process. (Output) 
5) return_code is zero if no error occurred. (Output) 


This Interface is Intended to remain chanzeable so that 
additional features can be put in, such as an indication that the 
tricks described itn Appendix I|l. are to be used. 


This entry creates an H-process and starts it running. The 
cal! to F in the new process is equivalent to: 


call F (arg_pointer); 

F must not be an internal procedure. The data pointed to by 
arg pointer must not Jie in a per-process sesment (such as the 
stack). : 

Entry: create_supervisor_task$make_process 

declare create_supervisor_task$make_process entry (1 like sdw, 
char (*), bit (36), pointer, bit (36)); 

call create_supervisor_task$make_process (pds_sdw, group_id, 


return_proc_id, return_aopt_ptr, return_code); 


1) pds_sdw is an SMW describing the PDS to be used by 
. the new process. (Input) 


2) group_id as above. (Input) 
3) return_proc_id as above, except right half must be set hy 


caller. (lnput/Output) 


= 45s 


4) return_apt_ptr points to the newly created APT entry. 


(Output) 
5) return_code as above. (Output) 
This entry provides a process in the stopped state. it is 


used in creating the idle process. 


B. DESTROY_ME 


This entry does not yet exist as it is not needed, 


Ge GETSEG 
Usage: 


declare get_segment entry (pointer, fixed binary, 
1 like sdw aligned, bit (36)); 
call get_segment (template, length, return_sdw, return_code); 


1) template is a pointer containing a segment number 
which can be used to look up segment 
attributes In the SLT. (Input) 


2) length is the number of words which must be created. 
CIinput) 

3) return—sdw is an SDW which describes this segment. 
(Output) 

4h) return_code is zero iff the operation succeeded, 
(Output) 


For example, a PDS for a new process may be created by: 


call get_segment Caddr (pds$), pds$copy_lensth, pds_sdw, code); 


D. WAIT’ and NOTIFY' 
Entry: pxss$wait_on_counter 
declare pxss$wait_on_counter entry (fixed binary, fixed binary, 


; fixed binary (71)); 
call pxssSwait_on_counter (Cevent_cell, last_state, timeout); 


1) event_cell is the shared state ceil. (!nput) 


2) last_state is a saved copy of the event ceil. Clnput) 
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3) timeout is an upper bound on wait time. (Input) 


Notes 


timeout is not presently implemented; ft fs a placeholder. 
This entry is normally used as follows: 


ee last_state = event_cell; 
if should_run then run; 
else call pxss$wait_on_counter (event_cell, last_state, 
| 3e6); 
goto L;. 
Entry: pxss$step_counter 


declare pxss$step_counter entry (fixed binary); 
call pxss$step_counter (event_cell); 


1) event_cell | as above. (Input/Output) 


This entry ts used to record the occurrence of an event. 


Appendix V 
Jargon explained 


PDS stands for Process Data Segment. It contains data 
biocks that once were [fn three distinct per-process. segments 
(pds, pdf, and process_info). Some of the data must remain in 
core, so the first page is wired as long.as the process is 
eligible. The data items are referenced through links (e.g. 
declare pds$apt_ptr external;) so they must have the same virtual 
address in all processes, although the data is per-process. This 
is accomplished by using the same segment number in each process 
for the per-process segment, and by having the same data layout 
within each segment. The PDS also serves as execution stack for 
ring zero for both call-side and fault-side programs. So that 
the ring-crossing hardware will work, the PDS is aiso reachable 
by another segment number which is the first In a group of eight 
reserved for stacks. 


PRDS stands for Processor Data Segment. There is one PRDS 
for each CPU in the system. It contains a fairly small data 
block and an execution stack for those faults and Interrupts that 
must not cause further faults, e.g. page faults and I[/0 
interrupts. The entire PRDS is wired down. 


DSEG stands for Descriptor Segment. This is used by the 
hardware to map segment numbers into segments: it defitnes the 
address space. It may be thought of as ae set of hardware 
registers. The first page of the DSEG [fs temn-wired whenever the 
process is loaded. . : 


The machine Instruction LDBR Is used to switch the CPU to a 
new DSEG descrihed by a given DBR (Descriptor Base Register) 
value. . 


SDW stands for Segment Descriptor Word. Each entry in the 
DSEG is an SDW for one segment. The SDW merely points to the 
page table for the segment, or specifies that a segment fault is 
to be caused. 


An abs-seg is a reserved hardcore segment number for which a 
null SOW fs present most of the time. Supervisor programs 
fabricate an SDW, stick it in the DSEG, reference the segment for 
a while, then clear the DSEG slot. This is useful in getting 
around such problems as addressing directories not known in this 
address space. 


ASTE stands for Active Segment Table Entry. The primary 
content of the ASTE is a page table. The AST Is therefore the 
data block containing all page tables, and is part of the wired 
segment sst. 


APTE stands for Active Process Table Entry. The APTE is 
forty-eight words long, and contains ali the data about a 
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particular process needed by traffic control. The APT fs 
therefore the data block containing an APTE for each process, and 
is allocated in the wired segment tc_data. 


oxss stands for Precess Exchange Switch Stack, combining the 
names of two older traffic control modules. Currently pxss 
contains the bulk of traffic control. 


Eligible processes are those to which enough core has been 
committed for them to run. Eligibility can be revoked after one 
cpu second if the process fs running outside ring zero; otherwise 
it can only be lost by an explicit call to BLOCK. Eligibiltty 
entitles the holder to absolute pre-emptive priority over = any 
process which subsequently becomes eligible. 


To load a process, the first pages of PDS and DSEG are read 
into core and temp-wired. <A process will be loaded (by pxss) = as 
soon as possible after it Is awarded eligibility, and ttnloaded 
when it loses eligibility. 


KST stands for Known Segment Table. It is primarily used at 
segment-fault time to find a segment that must be made active. 
Hardcore segments are not in the KST as they are always active. 


PDIR stands for Process Directory. This fis a per-process 


directory in which an M*process may create its temporary 
segments. . 
P!IT stands for Process Initialization Table. t!t is not used 


by hardcore. The outer ring programs of an M-process can find 
thelr process-creation parameters in this segment. 


DST stands for Device Signal Table. This is a data block 
used by some 1/0 interfaces, and Is currently allocated jin 
tc_data immediately after the ITT, although [it has nothing to do 
with traffic control. 


{TT stands for tnterprocess Transmisston Table, tt is a 
message queue used to pass information with [nterprocess wakeuns. 
{t is currently allocated in tc_data between the APT and the DST. 


M-process is a new term, from MPM process. It designates 
the type of process Multics has traditionally supplied for each 
user: cumbersome and expensive, but able to use all of the 
features of the Multics environment. An M-process always has an 
unshared address space, implemented with an unshared KST and 
DSEG. It always has a distinct PDIR in which to store its many 
per-process segments. 


H=process is a new term, from hardcore-only process. It 
designates a process which can reference only hardcore segments, 
using a mostly-shared address space, Since even M-processes 
already have. identical address spaces for most ring zero 
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segments, and the system is coded to take advantage of this, the 
H-process does not create any unusual programming restrictions. 


An idle process is a fiction of traffic control. There 
one per CPU, and it is run whenever there is nothing useful f 
that CPU to do. It is not supposed to take page faults becau 
that might cause fit to become unrunnable. An idle process has an 
unshared PONS and DSEG, and in the current implementation may be 
considered an H-process. 
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